Polishing Design Flaw Definitions

Every single false positive that an automated design flaw detection tool presents to a developer places a cognitive burden on him and should thus be avoided. A preliminary yet already quite comprehensive catalog of false positives was recently presented in [1]. We elaborated in [5, 4] that developers accept design flaws in the context of specific design ideas, e.g. feature envy in the context of the visitor pattern. We suggested that it should be possible to incorporate such knowledge into operational design flaw definitions. Inspired by [2] we are convinced that our understanding of the phenomena “design flaw”, “design idea” and their conflict could still benefit from an exploratory case study guided by the following research questions: What is the nature of design ideas that are related to design flaws? How are both related? What are the consequences for operational definitions of design ideas and design flaws?